Mobile communications is an area of growing importance. To facilitate mobile communications various protocols and standards have been developed. Mobile IP (MIP) is an example of one such protocol. Different versions of MIP are currently in use. To understand the invention, it is useful to understand some Mobile IP basics. Mobile IP (v4/v6), also indicated as MIPv4 and MIPv6, enables a mobile node (MN) to register its temporary location indicated by a care-of-address (CoA) to its Home Agent (HA). The HA then keeps a mapping (also called a binding) between the MN's permanent address, otherwise called Home Address (HoA), and the registered CoA so that packets for that MN can be redirected to its current location using IP encapsulation techniques (tunneling).
The CoA used by a MN can be an address that belongs to a Foreign Agent (FA) when MIPv4 is used or it can be a temporarily allocated address to the MN itself in which case is called a collocated care-of-address (CCoA). The latter model also applies to MIPv4 while it is the only mode of operation in MIPv6.
Note that for the purpose of this document the terms CCoA and CoA as well as Registration and Binding Update (BU) are interchangeable since they are the corresponding terms for MIPv4 and MIPv6. The concepts and solutions described here are applicable to both MIPv4 and MIPv6 unless otherwise mentioned.
Various communications protocols and standards support handoffs, allowing a mobile node to change its point of attachment to the network from one access node to another access node. Handoffs may take place between links of the same technology (e.g.: 802.11) in which case this is called an intra-technology handoff or between links of different technology (e.g.: 802 and Flash Orthogonal Frequency Division Multiplexing [OFDM), in which case this is called an inter-technology handoff.
Inter-technology handoffs and even some intra-technology hand-offs are normally ‘Make Before Break’ in nature, i.e.: the MN has two (or more) independent link layer connections to two access nodes, e.g., access routers (ARs) at the same time, at least for a portion of the handoff. The time period during which the MN has two link layer connections may in some cases be extended for a long time. Although an IP handoff can be performed quickly, it is not necessary that one of the two links will be dropped immediately. Furthermore, it is also possible to create the second link without moving IP forwarding (hand-off) to it for some time. In these cases the MN will be receiving traffic from its HA via the FA it has previously registered with. The FA may be, e.g., an access router to which it is coupled. Thus, in the case of a handoff, the FA may be changed from a first access router to a second access router with the MN being coupled to both access routers for some period of time, e.g., by a wireless link. The FA is normally located in a Foreign network domain while the HA may be an access router in a home domain used by the MN to attach to the network while present in the home domain.
More traditional intra-technology handoffs such as that performed in an 802.11 system tend to be ‘Break Before Make’, which means that connectivity to the network through a current access point/router is lost so that connectivity via a new access point/router can be gained. In these scenarios handoff speed has to be maximized and some additional measures such us temporary tunneling between access routers, for in-flight packets to the old access router, often needs to be taken to eliminate packet loss.
Reverse tunneling in RFC3024 [RevTun] G. Montenegro, Ed. “Reverse Tunneling for Mobile IP”, revised Internet RFC 024, January 2001, introduces new packet loss concerns at the HA and also incurs similar packet routing issues as RFC3220 [MIPv4] C. E. Perkins, Ed., “IP Mobility Support for Ipv4”, RFC3220, January 2002 between Foreign Agents, during a handoff. In accordance with RFC3024 packets reversed tunneled to a HA from a MN or FA require a valid source address that is known at that HA, a valid source address being defined as the destination address, or CoA, that has been registered in the HA for the forward tunnel between the HA and that MIP node (MN or FA). If a valid address is not used, then the HA drops the reverse-tunneled packet according to the reverse tunnel mechanism of RFC3024. As a result packets that are reverse tunneled from a new CCoA at a MN, or a new CoA at a new FA, that arrive at the HA before the registration of that new CoA has been completed, will be dropped by the HA. In addition, any in-flight packets from the old FA will be dropped at the HA, once a visitor list at the HA has been updated with the new CoA at the new FA, or new MN CCoA from the new FA. This is because in either case the packet source address no longer matches the current CoA binding. In addition, whilst smooth handoff for MIPv4 may be achieved by using the Previous FA extension or Binding Update to the old access router, a corresponding solution does not exist for reverse tunneling during handoffs.
Simultaneous forward bindings are used in some mobile communication systems. Typically, each MN has one valid registration with a given HA and thus, only one HoA to CoA mapping exists in the HA at any one time. In some cases the MN can maintain multiple HoA to CoA bindings using a process called simultaneous bindings [SIMBIND] defined as part of MIP. In this case the HA replicates all downstream traffic and sends it to all the CoAs indicated in its multiple bindings. This duplicates the resources consumed in the network as well as on potentially expensive access links (e.g.: wireless links), which in a number of scenarios may be unacceptable.
Apart from the multiple copies of the traffic burdening the network, multiple copies of the same packet can create problems to Transmission Control Protocol (TCP) streams. e.g.: Multiple copies of the same TCP Ack may fool the TCP stack to think that there is congestion in the network and thus reduce or stop transmissions.
If the MN or the network operator does not want to incur the cost of simultaneous bindings the MN can not use multiple links at the same time. This is for two reasons.
Firstly, when MIPv4 is used with FAs, an FA will not forward traffic for a MN that has not registered with it. This is because FAs typically implement access lists that drop all packets that come from unregistered MNs for security reasons. This means that if the MN is registered with FA1 but also has connectivity to FA2, it can only send and receive traffic via FA1.
Secondly, MIPv4/v6 has a feature called reverse tunneling. This ensures that all uplink traffic from the MN goes via the HA before its final destination. The traffic is essentially tunneled back to the HA either by the MN itself or by the FA the MN is connected to. Similarly as before, the HA will not accept reverse tunneled packets from a given CoA or CCoA unless the MN registers that CoA/CCoA with it.
To improve tunneling functionality, another mechanism called “split tunneling” or “per flow movement” [FLOWMOVE] has recently been proposed in this area. According to this an MN can create multiple forward bindings (tunnels) and assign traffic filters on each of them so that only some type of traffic is forwarded over each particular tunnel. For example a dual technology 802.11 and FOFDM node can create two tunnels with its Home Agent so that all voice traffic goes over the tunnel terminating on the FOFDM interface while all the data traffic goes over the tunnel terminating on the 802.11 interface.
In view of the above discussion, it is apparent that there is a need for a new mechanism, that enables a MN to send upstream traffic over multiple links to multiple access nodes, whilst receiving downstream traffic over a single link from a single access node.